前言

settings中的middleware真的有人進去看過嗎！？而昨天我們看了request進middleware加工廠，那今天就來看看內部有什麼吧！

正題

當然就是先找一個middleware來看看

我們就看看第一個middleware吧～django.middleware.security.SecurityMiddleware
跟著路徑進去，會看到

其中的MiddlewareMixin就是我們今天的主角啦！！

這個就是我們的主角，但還記得昨天的self._middleware_chain是怎麼串的嗎！？回顧一下
middleware_chain會是由一個一個inner function去串連起來的

而其中的adapted_handler就是inner function

最後串出來的middleware大概會長得像這樣mid4(mid3(mid2(mid1())))
由此可知，MiddlewareMixininit時給的get_response就是inner function
最後_middleware_chain會在get_response function時被呼叫

而呼叫時會觸發的是inner中的邏輯

而其中的get_response(request)會去觸發MiddlewareMixin中的__call__()

那這邊就會一層一層的往裡面去處理request，這樣講解我自己都覺得有點抽象，我們一樣上圖來看看！

照目前資訊畫出來會長這樣，當然MiddleMixin其實不只這些官網範例還有其他項，但我們依照目前資訊畫出來的就如上圖，還有其中最重要處理view的邏輯在最裡面那層，也就是在load_middleware()的時候這個部分

其中的self._get_response就是我們明天的主角！！

結語

雖然現在已經看懂middleware在做什麼事情了，但我卻不太清楚什麼時機點會去用他（客製化）就是了，比較常看到的是第三方套件大概率會有自己寫的middleware去處理request或response，可能是我做過的專案不夠多不夠複雜吧～不過讀懂了之後遇到感覺可以套用的情境時，就是讓自己多了個選擇！！